fix(load): unblock first load of an absent extension - #54

Problem

The very first load of an extension that the infobase does not carry yet fails on the compatibility probe:

v8-runner --config <CONFIG> load --path <EXT>.cfe --extension <NAME> --mode load

validation error: failed to determine infobase compatibility state for extension '<NAME>'

Exit code 2, result artifact_load_failed. The main configuration is already loaded into a fresh file infobase at this point; only the extension is missing.

Reproduced on platform 8.3.27.2130, v8-runner 0.5.1 (7ce1b06, current master).

Downstream report: IngvarConsulting/unica#355

Root cause

load always runs probe_compatibility before applying the artifact. For a .cfe it runs Designer

/CompareCfg -FirstConfigurationType ExtensionConfiguration -FirstName <NAME> \
            -SecondConfigurationType ExtensionDBConfiguration -SecondName <NAME>

When <NAME> is not in the infobase, Designer exits non-zero with

Конфигурация 'Расширение конфигурации' недоступна

classify_probe_failure then returns Unknown, which probe_compatibility turns into AppError::Validation. Two independent gaps combine here, and both must be closed for the scenario to work:

1. to_ascii_lowercase() does not lowercase Cyrillic. It only maps A-Z, so "Расширение" never matches the literal "расширен". Every Russian branch of the classifier — не найден, не поддерж, and поддерж/поставщик on the configuration side — is unreachable whenever the platform capitalises the word, which it does. Verified:

   "Конфигурация 'Расширение конфигурации' недоступна"
     to_ascii_lowercase() -> contains("расширен") == false
     to_lowercase()       -> contains("расширен") == true
   

2. No vocabulary for the absent-extension wording. The classifier recognises only not found/не найден and not supported/unsupported/не поддерж. The platform says недоступна ("unavailable").

An extension missing from the infobase is the normal state before the first load, so it should classify as NotSupported: validate_probe_mode_compatibility(LoadMode::Load, NotSupported) returns None and the load proceeds.

Change

• classify_probe_failure uses Unicode to_lowercase().
• The extension arm treats недоступ/unavailable/not available as absent, alongside the existing not-found and unsupported wording.
• The two extension branches collapse into named absent / unsupported predicates; behaviour for previously recognised wording is unchanged.

This only widens classification of a probe that has already exited non-zero — a successful compare still returns Supported before reaching the classifier.

Tests

Three unit tests on classify_probe_failure:

• the exact platform message classifies as NotSupported;
• the English equivalent classifies as NotSupported;
• an unrelated extension probe failure stays Unknown, so the widened wording cannot silently mask a real failure.

The first two fail on master before the change (left: Unknown, right: NotSupported).

Verification

Run on 7ce1b06 before and after the change:

The 44 failures are pre-existing and environmental on this machine (no 1C platform installed); the sorted list of failing test names is identical before and after, so nothing regressed. cargo test --bin v8-runner load_artifact is fully green (15/15). cargo fmt --check passes, and cargo clippy reports no new warnings in the changed region.

I could not run the live-platform scenario end to end here — I have no 1C platform on this machine — so the platform-side confirmation is the reproduction in the linked downstream issue.

Summary by CodeRabbit

• Исправления

  • Улучшено распознавание ошибок, связанных с отсутствующими или недоступными расширениями.
  • Добавлена поддержка сообщений на русском и английском языках.
  • Обеспечена корректная обработка текста с учётом регистра Unicode.
  • Нерелевантные ошибки по-прежнему сохраняют статус «Неизвестно».

• Тесты

  • Добавлены проверки для русскоязычных и англоязычных сообщений, а также для нерелевантных ошибок.